8 أخطاء ارتكبناها (وكيف جعلت ONLYOFFICE أفضل)

16 عامًا هي فترة طويلة لإنشاء البرمجيات. وإذا كنا صادقين، لم نفعل كل شيء بشكل صحيح من المحاولة الأولى.

كجزء من سلسلة الذكرى السنوية الـ 16 الخاصة بنا، نريد مشاركة شيء مختلف قليلاً. ليس قائمة بالنجاحات، بل قائمة بالأخطاء التي ارتكبناها على طول الطريق، وكيف دفعتنا كل منها لبناء منتج أفضل. لأن هذه هي الحقيقة: تم بناء ONLYOFFICE من الصفر، داخليًا، بواسطة فريق كان يتعلم أثناء تقدمه. كل منعطف خاطئ علمنا شيئًا يفيد الآن أكثر من 21 مليون مستخدم لدينا.

1. البدء بتجربة تحرير تعتمد على إضافة

في الأيام الأولى، حوالي عام 2010، كانت تجربتنا الأولى في تحرير المستندات تعمل على OpenOffice. لتحرير مستند، كان عليكم تنزيل إضافة، وفتح الملف، وحفظه مرة أخرى في البوابة بعد ذلك.

لقد نجح الأمر. نوعاً ما. لكن التحميل استغرق وقتًا طويلاً جدًا، وكانت النتائج غير متوقعة، وبدا الأمر وكأنه حل بديل أكثر من كونه منتجًا حقيقيًا. احتاج كل مستخدم إلى برامج إضافية على جهازه لمجرد البدء.

ما تعلمناه: يجب أن تتم تجربة التحرير الرائعة مباشرة في المتصفح، دون أي خطوات معقدة في المنتصف. حدد هذا الإدراك الاتجاه لكل ما جاء بعد ذلك.

2. بناء المحررين باستخدام CKEditor وتصيير DOM

بعد ذلك، حاولنا بناء المحررين لدينا باستخدام CKEditor وتصيير DOM، بما في ذلك محرر جداول البيانات. ما هي المشكلة؟ يعرض كل متصفح الأشياء بشكل مختلف. ما رأيتموه على الشاشة لم يكن دائمًا ما تحصلون عليه عند الطباعة. أدت الملفات الكبيرة إلى إبطاء كل شيء بشكل كبير، وجعلت حدود الذاكرة العمل الجاد شبه مستحيل.

ما تعلمناه: كنا بحاجة إلى تحكم كامل في كيفية عرض المستندات وطباعتها، عبر كل متصفح وجهاز. دفعنا هذا إلى أن نصبح أول من يبني محررين عبر الإنترنت باستخدام عنصر HTML5 Canvas، مما يمنح المستخدمين نتائج متسقة وموثوقة بغض النظر عن مكان عملهم.

3. حساب معادلات جداول البيانات على الخادم

إليكم أمر آخر. في محرر جداول البيانات الأولي الخاص بنا، قمنا بحساب المعادلات على الخادم وعرضنا النتائج فقط على متصفح المستخدم. على الورق، بدا الأمر فعالاً. لكن من الناحية العملية، أدى ذلك إلى حدوث تأخيرات وحدّ من مدى تفاعلية التجربة.

ما تعلمناه: يتوقع المستخدمون استجابة فورية عند العمل مع الأرقام. أدى نقل العمليات الحسابية لتصبح أقرب للمستخدم إلى جعل المحرر أسرع وأكثر استجابة بكثير، وهو بالضبط ما يحتاجه الأشخاص للعمل اليومي.

4. استخدام .NET و C# على الخادم

كانت هذه واحدة من أكبر نقاط التحول بالنسبة لنا. في الأيام الأولى، اخترنا إعداد .NET و C# للمحررين لدينا ببساطة لأننا لم نكن نملك بعد الخبرة الكافية لمعرفة ما هو الأفضل.

سرعان ما أصبح واضحًا أن هذا النهج لم يكن مناسبًا. لم يكن يعمل على نظام Linux، وكان الأداء بطيئًا حتى على نظام Windows، وكان التعامل مع العديد من الاتصالات المتزامنة أمرًا صعبًا.

لذلك اتخذنا قرارًا جريئًا وأعدنا كتابة الخادم باستخدام Node.js. في ذلك الوقت، كانت لا تزال تقنية جديدة وتجريبية للغاية، ولم يعتقد الجميع أنها الخطوة الصحيحة. لكن أبحاثنا واختباراتنا أخبرتنا بخلاف ذلك. في النهاية، قمنا بإعادة بناء الخادم بالكامل من الصفر.

ما تعلمناه: أحيانًا يكون أشجع قرار هو البدء من جديد. منحت إعادة بناء الخادم لـ ONLYOFFICE السرعة والاستقرار والمرونة عبر الأنظمة الأساسية التي يعتمد عليها مستخدمونا اليوم. وبنفس القدر من الأهمية، ساعدتنا هذه التجربة في اتخاذ خيارات معمارية أفضل لاحقًا عند بناء DocSpace، حتى نتمكن من تجنب تكرار نفس الأخطاء.

5. المراهنة على صيغ DOCXF و OFORM الخاصة بنا

للتعامل مع نماذج تعبئة، قدمنا الصيغ الخاصة بنا في عام 2022: DOCXF و OFORM. كانت الفكرة منطقية في ذلك الوقت، لكن تغيير عادات الناس أمر صعب. أضافت مطالبة المستخدمين بتبني صيغ غير مألوفة احتكاكًا حيث أردنا البساطة.

لذلك قمنا بالانتقال إلى PDF، وهي صيغة يعرفها الجميع ويثقون بها بالفعل.

ما تعلمناه: تلبية احتياجات المستخدمين حيث هم بالفعل أفضل من مطالبتهم بالتكيف معنا. الآن يمكنكم إنشاء وتعبئة نماذج PDF باستخدام أدوات تبدو مألوفة على الفور.

6. الإطلاق بدون تطبيق جوال أصلي

لفترة من الوقت، لم تمتلك ONLYOFFICE تطبيقات جوال أصلية. كان لدينا تصميم متجاوب بالتأكيد، لكن ذلك لم يكن كافيًا. أراد الناس تجربة حقيقية ومصممة خصيصًا على هواتفهم وأجهزتهم اللوحية.

ما تعلمناه: التصميم التكيفي هو البداية، لكن التطبيق الأصلي الحقيقي هو ما يريده الناس بالفعل أثناء التنقل. اليوم، يمكنكم استخدام تطبيقاتنا المجانية لـ iOS و Android للعمل على المستندات في أي مكان وفي أي وقت.

7. عدم بناء واجهة برمجة تطبيقات (API) عامة منذ البداية

لم نقدم واجهة برمجة تطبيقات عامة على الفور. بالنظر إلى الوراء، كانت تلك فرصة ضائعة. تجعل واجهة برمجة التطبيقات سهلة الاستخدام من السهل على أي شخص ربط ONLYOFFICE بالأدوات التي يستخدمونها بالفعل، وتلعب الـ تكاملات دورًا كبيرًا في منظومتنا.

ما تعلمناه: الانفتاح يدعو إلى النمو. بمجرد أن قمنا ببناء واجهة برمجة تطبيقات يمكن الوصول إليها وواضحة، تمكن المطورون والمنصات من دمج ONLYOFFICE بسهولة. ما زلنا نقوم بتوسيعها وجعلها أكثر ملاءمة مع كل إصدار.

8. عدم التخطيط للـ تكاملات في وقت مبكر بما فيه الكفاية

درسنا الأخير مرتبط ارتباطًا وثيقًا بالدرس السابق. للسماح للتطبيقات الأخرى بالاتصال بمنتجكم وتوسيع ما يمكنه القيام به، تحتاجون إلى التخطيط لقدرات “المنصة” هذه مسبقًا. في سنواتنا الأولى، لم نفعل ذلك دائمًا.

ما تعلمناه: البناء من أجل الـ تكامل منذ اليوم الأول يوفر جهدًا هائلاً لاحقًا. هذه هي بالضبط العقلية التي نجلبها إلى ONLYOFFICE DocSpace اليوم، حيث تم تصميمه ليتصل بسلاسة مع الأدوات التي تعتمد عليها الفرق بالفعل.

ما علمته لنا كل هذه الأخطاء

بالنظر إلى الوراء، يظهر نمط واضح. كل واحدة من هذه الأخطاء جاءت من نفس المكان: فريق يبني كل شيء من الصفر، بدون طرق مختصرة وبدون دليل عمل لشخص آخر لاتباعه.

إليكم ما قدمته لنا سنوات التجربة والخطأ هذه:

• الشجاعة لإعادة البناء عندما لم يكن هناك شيء جيد بما فيه الكفاية؛
• الالتزام بتجربة المتصفح أولاً التي يحبها مستخدمونا؛
• نهج مفتوح وصديق للمطورين يدعم أكثر من 40 تكاملاً؛
• عادة الاستماع والتكيف مع ما يحتاجه الناس بالفعل.

لم نصل إلى هناك بكوننا مثاليين. لقد وصلنا إلى هناك باستعدادنا للتعلم.

تستمر الرحلة

بعد مرور 16 عامًا وأكثر من 21 مليون مستخدم، نحن فخورون بالمدى الذي وصلت إليه ONLYOFFICE، وصادقون بشأن العقبات على طول الطريق. كل خطأ جعلنا أفضل، وكل إصلاح قربنا أكثر من المنتج الذي يستحقه مستخدمونا. لم يتباطأ هذا الدافع للاستمرار في التحسن ولو قليلاً.

هل ترغبون في رؤية إلى أين أدى كل هذا التعلم؟ استكشفوا سلسلة الذكرى السنوية الـ 16 الكاملة لـ ONLYOFFICE واكتشفوا المعالم والقرارات واللحظات التي شكلت من نحن اليوم.